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IMPROVED TELECOMMUNICATIONS SYSTEMS AND METHODS 

5 

CROSS REFERENCE TO RELATED APPLICATIONS 
This application is a continuation in part of, and 
claims the benefit of, U.S. Provisional Patent Application No. 
10 60/046,240, filed May 12, 1997, the complete disclosure of 
which is herein incorporated by reference. 

BACKGROUND OF THE INVENTION 
_ This invention relates generally to the field of 

15 telecommunications, and in particular to Operational- Support 
Systems and methods for their use. 

Operational Support Systems (OSS) are a broad 
category of systems that support planning, provisioning, 
installation, maintenance, operation, and engineering and 

20 administration of network elements, networks and services. 

Additionally, OSSs include systems to negotiate orders, and to 
rate and bill for usage of services. 

Factors such as deregulation, competition, 
consolidation, convergence and globalization are changing the 

25 nature of the telecommunications industry. The result of 

these factors is that telecommunication companies are finding 
it increasingly more important to reduce costs, deploy 
existing products more quickly, and offer more services to 
maintain and grow market share. The flexibility, scaleability 

30 and usability of OSSs directly influences the ability to offer 
services quickly and cost effectively. 

Many existing service providers, such as RBOCs, find 
that their existing OSSs are too fragile, constraining, and 
costly to meet the demands of a competitive marketplace. 

35 Hence, it would be desirable to provide both new and existing 
service providers with an improved operational support system 
to enable them to offer their services conveniently, quickly 
and cost effectively. 
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OBUECTS OF THE INVENTION 
OSS users include network providers and managers 
(connectivity providers) , network designers and developers, 
retailers, content providers, service providers and managers, 
5 service subscribers (brokers) , service users (consumers) , and 
operators and administrators. It would be desirable if all 
such users could share a common user experience when 
interfacing with an OSS. More particularly, it would be 
desirable to provide the OSS with intelligent . components and 

10 data models to integrate heterogeneous elements into a 

concrete, homogenous view. It would further be desirable if 
such interfaces were aware of new services, management 
functions, or resources installed into the system. Such 
components- should also be able to discover, obtain and display 

15 an editor or viewer associated with the new service, 

management function or resource. It would also be desirable 
to incorporate artificial intelligence to evaluate work in 
progress and offer suggestions to the user to insure that the 
work is complete and accurate. 

2 0 Further, it would be desirable if tasks perfoirmed 

within the OSS were configured to be straight foirward, 
consistent, and repeatable. In this way, the learning curve 
for interfacing with the system would be greatly reduced. 
Further, the need for systems specific experts would be 

2 5 reduced, as well as the time to implement a new service, 

management function or resource. 

It is another object of the invention to provide an 
OSS with a single enterprise data model. Such a model should 
be layered and hierarchial and be configured to support data 

3 0 abstraction and minimize dependency between layers in the 

model. It would further be desirable if the data model were 
template based to facilitate introduction of new data models. 
Further, such a configuration should allow for the rapid 
introduction of new kinds of data models, to provide a single, 
3 5 common view of data models, and eliminate synchronization 
inaccuracies between users of the data. 

It is still a further object of the invention to 
provide an OSS with the ability to reflect the service 
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provider's business strategy, policies and standards in work 
flow and business rules. Also, the ability to rapidly change 
and validate work flow and business rules in response to 
changes in strategy, policies and standards should be 
5 provided. In another aspect, it would be desirable to collect 
metrics and measurements throughout the system. The OSS 
should also support separation and interoperability between 
business domains and authorities. Such features should allow 
the service provider to be differentiated in their marketplace 

10 as well as to provide control and accountability. 

In still a further object, it would be desirable if 
the invention provided open, standards compliant architecture, 
which includes intelligent (domain aware) components that 
discover and utilize services, management functions and data 

15 models provided by other components. The invention should 
also support distributed processing and "plug-and-play" 
scaleability . It would further be desirable if the invention 
provided a layered, open architecture that supports 
scaleability through process and data abstraction, permits 

2 0 multi -vendor solutions, and permits integration of different 
technologies, as well as supporting piece wise replacement of 
legacy systems. In this way, the invention will allow for 
rapid introduction of new services and management functions, 
as well as permitting vendor competition. 

25 

SUMMARY OF THE INVENTION 
The' J.nvention provides exemplary systems and methods 
for overcoming or greatly reducing the drawbacks of prior art 
telecommunication systems, as well as providing solutions to 

30 the objects of the invention. In one exemplary embodiment, a 
telecommunication system is provided which is useful in 
connection with at least one network element . The system 
comprises a plurality of platforms, each of which has a 
defined functional responsibility. A plurality of components 

35 are selectively attachable to the platforms. The components 

of each platform are configured to operate together to perform 
various tasks within the functional responsibility of the 
platform. Further, one of the platforms is adapted to be 
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placed in communication with the network element to allow 
configuration information to be transmitted from the platform 
to the network element. In this way, the telecommianication 
system may be arranged in functional layers (according to the 
5 platforms) , with the platforms functioning as a unifying 

element within each layer to provide common services to its 
components, to orchestrate work between components, as well as 
to provide standards, rules, and principles for component 
granularity and location. In turn, the components are 

10 provided to perform the actual work within the platform. 

In one particular aspect, a gateway is further 
provided to interconnect at least some of the platforms.- The 
gateway includes any electronic interface to place the 
interconnected platforms in communication with other service'' 

15 provider systems. In this way, the system of the invention 

may easily interface with the systems of other carriers. In a 
further aspect, mediators are provided to interconnect each of 
the platforms. The mediators include code to translate 
information which is transmitted between platforms. In this 

2 0 way, the "view" of a domain may be translated between the 

platforms . 

Preferably, the defined functional responsibilities 
for the platform will include customer service management, 
network service management, network management, network 
25 element management and the like. One advantage of the 

invention is that a variety of components may be selectively 
placed into the platforms. Such components may include, for 
example, network management systems, service order management 
systems, order entry systems, monitoring systems, rating and 

3 0 billing systems, inventory systems, work force administration 

systems, rating systems, capacity planning systems, network 
operation systems and the like. Preferably, each platform " 
will include a bus to channel information between each of the 
components in the platform. 
35 In a specific aspect, one of the platforms comprises 

a network element management platform which is adapted to 
interface with a plurality of network elements, such as STPs, 
SCPs, SSPs and the like. The system will also preferably 
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further include a data model which is placed in communication 
with at least some of the platforms. The data model includes 
code for providing the state, attributes and behavior of 
telecommunications domain objects. In this way, various 
5 information regarding telecommunications domain objects will 
be accessible to the components when performing a task. In a 
further aspect, at least one of the platforms will include at 
least one user interface, such as graphically user interfaces 
to allow a user to access the information within the system. 

10 The invention further provides an exemplary method 

for providing telecommunication services. According to the 
method, a plurality of platforms are provided which are each . 
assigned a functional responsibility. At least one component 
is selectively placed into each of the platforms so that the 

15 component may perform a task within the functional 

responsibility of the platform. In this way, components in 
the platforms translate the services as understood by the 
consumer of the service into the information necessary to 
configure a network and network elements to deliver the 

2 0 service. 

Each of the platforms is preferably configured to 
provide common services to each of its components to allow the 
components to perform their given tasks. For example, the 
platforms will preferably facilitate work flow between the 

2 5 components to allow the components to cooperate together to 

perform various tasks within the functional responsibility of 
the platform. Such functional responsibilities may include, 
for example, customer service management, network service 
management, network management, network element management and 

30 the like. The platforms will also preferably be configured so 
that they will be able to determine the type of component upon 
placement into a platform. In this way, a variety of 
components may be easily * introduced into a platform. 

As one example, the components may be selected to 

35 provide a local number portability task. The transmitted 

information will then comprise call routing information which 
provisions the network elements. 
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In another aspect of the method, at least some of 
the telecommunications information will preferably be 
translated when transmitted between platforms. 

Telecommunications information which is transmitted to another 
5 service provider's telecommunication system will preferably 
also be translated. Conversely, telecommunications 
information received from another service provider will 
preferably be translated before being transmitted to the 
platforms . 

10 Conveniently, information from the components and 

business rules associated with the operation of the components 
may be accessed with a graphical user interface. In still 
.another aspect, the state, behavior and usage information 
relating to telecommunications domain objects will preferably 
1*5 be transmitted to at least one of the platforms to assist the 
components in performing a task. Such information may 
include, for example, network element requirements, facilities 
requirements, work force requirements, and the like that are 
needed to accomplish a task. 
20 In still yet another embodiment, an exemplary method 

is recited for providing telecommunications services. 
According to the method, a telecommunication service is 
ordered and entered into an order entry component that is 
interfaced with a service management (customer facing) 
25 platform. A data model is queried through the service 

management (customer facing) platform to determine if the 
product is available for order. If available, information 
relating to the order is transmitted to a service management 
(network facing) platform having an order management 
3 0 component. The data model is again queried through the 

service management (network facing) platform to determine the 
particular resources that will be required to service the 
order. Information relating to the order is then transmitted 
to a network management platform to determine if the 
3 5 particular resources are in fact availsible to service the 
order. Finally, information relating to the order is 
transmitted to network element management platform to 
provision or configure the service on a network element. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 illustrates a conceptual model of an 
exemplairy telecommunications system according to the 
invention . 

5 Fig. 2 illustrates a schematic view of one 

embodiment of an exemplary telecommunications system according 
to the invention. 

Figs. 3A-3D illustrate four types of components that 
may be coupled to the telecommunications : systems of Figs. 4-6. 
10 Fig. 4 is a schematic view of an embodiment of a 

telecommunications system illustrating various products and 
services which are coupled to the system according to the 
invention. 

Fig. 5 is a detailed view of a service management 
15 (customer facing) platform and a service management (network 
facing) platform of a telecommunications system according to 
the invention. 

Fig. 6 is a detailed view of a service management 
(customer facing) platform and a service management (network 
20 facing) platform of a telecommunications system to which a 

local service request management product is coupled according 
to the invention. 

DETAILED DESCRIPTION OF THE SPECIFIC EMBODIMENTS 

2 5 The invention provides exemplary telecommunication 

systems and methods for their use. The systems comprise an 
OSS having layers of platforms and components that may be 
selectively interfaced with each of the platforms to perforin 
various tasks. The OSS of the invention is based on 
30 telecommunication management network (TMN) architecture that 
organizes service and management functions into layers. Each 
layer of the OSS abstracts and comprehends the use of the 
services and management functions available in the next lower 
level, enabling scaleability and flexibility by promoting data 

3 5 and process abstraction. 

According to the invention, OSS applications 
comprise collections of components that provide services and ' 
management functions necessary to automate telecommunications 
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business processes. The components are organized into the 
layers of the TMN architecture and collaborate to perform a 
kind of task. Further, such applications are typically not 
independent, i.e., the components of an application may rely 
5 on other services and management functions which in turn are 
provided by other components within the same layer. To 
facilitate such cooperation, the OSS of the invention includes 
a management platform within each layer to establish interface 
and functionality standards, to apply business rules and 
10 logic, and to provide common services to all components within 
a layer. 

The OSS of the invention further includes an 
enterprise data model that maintains information and resource 
models (products, services, equipment and the like) that are 
15 accessible by multiple OSS applications or decision support 

systems. The enterprise data model is hierarchial in the same 
manner as the TMN architecture such that the data models 
available to components within a level are at the appropriate 
level of abstraction. The OSS of the invention further 

2 0 includes integration with work flow managers to provide a 

flexible mechanism to define business processes. Optionally, 
integrated user interfaces may be employed to tie diverse 
information into a common presentation for a user. 

A conceptual model of an OSS 8 is illustrated in 
25 Fig. 1. As shown, the various platforms or software buses are 
arranged into layers which conform generally to the TMN 
layers, i.e. a service management layer (customer/retail) , a 
service management layer (network/wholesale) , a network 
management layer, and an element management layer. The 

3 0 various platforms may communicate with each other through a 

mediator. Further, the platforms may communicate with 
external systems, including other service provider systems, 
through adapter components, such as fax, e-mail, EDI, and the 
like. 

35 The platforms are configured such that various OSS 

application components and/or common service components may be 
coupled to the platforms. Information from each of these 
components may be accessed and/or transferred through the 
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platforms and mediators. Further, each platform includes an 
enterprise data model . This enterprise data model includes 
information model service components and domain model 
components. The service components can include databases for 
5 storing data received or extracted from other components in a 
relational representation, report tools and facilities, and 
the like. The domain model components include services that 
model entities involved in telecommunication business 
processes for operations, planning and engineering, service 
10 provisioning, and customer care and billing. These ' entities , 
which are presented by objects, model both state (attributes) 
and behavior, and can include, for example, customer, product, 
service, order and network elements. 

As previously mentioned, the - platforms provide 
15 access to common software services for applications through a 
software bus, using Application Programming Interfaces (APIs)-, 
to facilitate eff icient • development and integration of OSS 
application components for service providers into a common 
run-time environment. This is accomplished by providing easy 
20 access to reusable common services that allow application 

development efforts to focus on improved functionality rather 
than the underlying common processes of such applications. 
The published APIs for the common software services also 
facilitate adaptation of existing applications to this common 
25 run-time environment which, in conjunction with the enterprise 
data model, provides consolidated information sharing and 
reporting with various products,, including products offered by 
other application developers (vendors) . 

The software bus thus enable various OSS application 
3 0 components, which are appropriately compliant with published 
standards and APIs, to access and utilize common software 
service components, as well as to utilize the enterprise data 
model to retrieve information from and share information with 
other applications within the OSS. Further, such information 
3 5 may be received from or shared with other OSS's and external 

applications. The software bus preferably enables layering of 
software applications in accordance with the ITU-T TMN 
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architectural modal and utilizes a widely accepted or industry 
standard Object Request Broker, e.g. CORBA-compliant . 

Referring now to Fig. 2, an exemplary embodiment of 
an OSS 10 will be described. OSS 10 comprises a plurality of 
5 platforms, including a service management (customer facing) 
platform 12, a service management (network facing) platform 
14, a network management platfonn 16, and a network element 
management platform 18. Interfaced with the various platforms 
are different components 2 0 which are responsible for 

10 performing various tasks as described in greater detail 
hereinafter . 

The various platforms are the unifying element 
within each layer of OSS 10. As such, the platforms comprise 
various software services, middleware frameworks and 

15 standards. Each of the platforms has a defined functional 

responsibility. For example, platform 12 is responsible for ■ 
customer facing service management . Platform 14 is 
responsible for network facing service management, while 
platform 18 is responsible for network management. Finally, 

20 platform 18 is responsible for network element management. A 
plurality of network element management systems 22 are 
interfaced with platform 18 to assist in provisioning or 
configuring various network elements 24. 

The specific functional responsibilities of the 

25 platforms may include, for example, the collection and 

evaluation of metrics and measurements, and the collection and 
evaluation of '.alarms, status, and error information. The 
platforms may further provide access to components 2 0 and to 
resources from an enterprise data model 26 at the platform's 

30 level. The platforms further encapsulate and enforce business 
rules, e.g., validation and verification, applicable to a 
platforms level. The platforms further provide communication 
(transport) between components 2 0 and data model 2 6 at the 
platform's level. Further, the platforms enforce layered 

35 architectural principals by defining standards for the 

construction of components 20 for each layer of OSS 10. The 
platforms further provide APIs, protocol stacks, frameworks, 
and the like. The platforms are also employed to produce 
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Standards for implementation, integration and migration of 
components 20 and data model 26 into the platforms. 

The platforms are further configured to provide a 
variety of common services including: security, persistence/ 
5 transaction management, naming and directory services, 

underlying protocol transparency, alternate messaging routing, 
resource discovery, and the like. Such platforms further 
provide standard interfaces or gateways to work flow 
management and to data model 26. Such platforms also provide 
10 access to services and resources for presentation, i.e., user 
interfaces . 

Another specific function of the platforms is to 
provide for work flow management . Work flow provides a 
mechanism to orchestrate a wide variety of actions to 

15 accomplish a task. This is particularly important when a 
situation requires human intervention. Hence, work flow 
provides a mechanism to hand-off and track a task assigned to 
an individual or organization. Additionally, work flow also 
provides a mechanism for defining and implementing business 

20 processes, particularly in regard to handling exception cases. 

Accessible through each platform, each component 2 0' 
will preferably have an API that permits integration with a 
work flow manager. In instances where work flow management is 
not required, the platform will preferably orchestrate work in 

25 accordance with imbedded rules. 

The application areas provide an organizing 
principle for the development and integration of components 
that perform a kind of task. Components within each 
application do not necessarily function in isolation, rather 

3 0 they may rely on services and management function provided by 
other components within the layer. Such application areas 
preferably include operations, planning and engineering, 
service provisioning, and customer care and billing. The 
operations applications can include, for example. Advanced 

35 Intelligent Network (AIN) services, human resources, payroll, 
financials, network operations and fault management, field 
service and repair, security and work force management, and 
the like. 
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Planning and engineering is focused on network 
design, decision support, product planning and development, 
and the like. Some areas of service provisioning include 
configuration management, inventory management, provisioning, 
5 service activation, service order processing and the like. 

Finally, customer care and billing includes applications for 
billing, customer support and service, pricing, rating, sales 
and marketing, and the like. 

The following table lists examples of applications 
10 within each category mapped to the TMN layers. 

TABLE 1 



15 





Operations 


Planning and 
Engineering 


Service 
Provisioning 


Customer 
Care and 
Billing 


BML 








• Chttfn Management 

• Demand forec^sung 


SML 


• Product planning 


• Product design 

• Capacity planning 


• Order entry 

• Order management 


•Wholesale and retail 
ratiftg and billing 


NML 


• Woric force a<lmintstr3tton 

• Fault management 


• Service design 

• Drcuit design 


* Physical and virtue 
inventory manaq|ement 


• Usage collection and 
mediation 


EML 


• Monitonng 




• LNP NEMS 




NEL 











A wide variety of components 2 0 may be provided to 
20 accomplish the various tasks required to provide the OSS 

services. Exemplary components which may be used with the 
invention include: network management systems, service order 
management systems, order entry systems, monitoring systems, 
billing systeins, inventory management systems, work force 
25 administration systems, rating systems, capacity planning 
systems, network operations systems, service provisioning 
management systems, and the like. Exemplary network 
management systems, service order management systems and order 
entry systems are described in copending U.S. Provisional 
30 Applications Serial Nos . 60/033,421, 60/033,422 and 

60/033,423, all filed on December 24, 1996, and U.S. Patent 
Application Serial Nos . 08/907,323, filed August 6, 1997 and 
08/906,751, filed August 6, 1997. The con^lete disclosures of 
all these applications are herein incorporated by reference. 
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Enterprise data model 2 6 provides a single (logical) 
repository of shared data and resource models used in OSS 
applications and decision support systems. The shared data 
and resource models are preferably hierarchial in the same 
fashion as the TMN layers providing the appropriate level of 
abstraction for components within a layer. The following 
table illustrates the kinds of models that may be present 
within each layer of the TMN architecture. 

TABLE 2 





Models 


BML 


• Markets, marnet segments 


SML 


• Products (available services) 


NML 


• Service Elements 

• Equipment 

• Outside Rant 


EML 


• Netwont element (mirrxir) 


NEL 





The enterprise data model is configured to provide 
the current state, behavior and usage constraints. Such 
information is made available to the components 2 0 to perform 
their various tasks. 

To enhance useability, selective user interfaces 2 8 
may be provided. Due to the nature of the OSS architecture, a 
task or a similar set of tasks may involve multiple components 
and resources." Interface 28 provides a common framework to 
unite the presentations of multiple components and to data 
model 26, providing a common look and feel through consistent 
presentation, navigation and help. 

Positioned between some of the platforms is a 
mediator 3 0 which includes code to translate information which 
is transmitted between the platforms. In this way, a 
particular "view" of a domain may be translated between the 
various platforms. OSS 10 further includes a gateway 32 which 
interconnects other service provider systems, such as system 
34, with platfoirm 12, and acts as a mediator between platforms 
12 and 14 . 
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An exemplaify method for employing OSS 10 to provide 
various telecommunications services will, now be described. In 
a typical application, a customer will order a 
telecommunication service which will be entered into one of 
5 components 20 in platform 12. Such a component will 

preferably be an order entry component which is employed to 
query data model 2 6 through platform 12 to determine of the 
ordered product is available for order. If available, 
information relating to the order is then transmitted to 

10 platform 14, which will preferably include an order management 
component. The order management component will then query 
data model 26 through platform 14 to determine the particular 
resources that will be required to service the order. Upon 
determining this information, the information will be 

15 transmitted and translated to network management platform 16 
. via mediator 30. Platform 16 will include various components 
which are employed to determine if the particular resources 
are actually available to fulfill the order and the steps 
necessary to fulfill the order. For example, the components 

20 on platform 16 may comprise a service activation component, an 
inventory component and a work force component. If everything 
is in order, the steps determined to fulfill the order are 
executed and information relating to the order is then 
transmitted to network element management platform 18 via 

25 mediator 3 0 so that the service may be delivered or configured 
by network elements 24. 

Hence, OSS 10 provides users with enhanced flexibility by 
allowing a wide variety of components to be inserted into the 
various platforms in order to accommodate various services 

30 provided by service carriers. Over time, as new services are 
added or old services are replaced, OSS 10 is able to easily 
accommodate such changes by simply allowing different 
components and objects to be replaced. Each of the platforms 
will preferably include middleware that will be able to 

3 5 determine the type of added component so that it may easily be 
.configured into the system. Hence, both scaleability and 
flexibility are provided to allow service providers to 
effectively compete in the telecommunications market. 



3NSDOCt& <WO 96S23g1A1 I > 




wo 98/52321 PCT/US98/09697 

15 

Referring now to Figs. 3A-3D, various components 
which may be coupled to the telecommunications systems of 
Figs. 4-6 will be described. Shown in Fig. 3A is an OSS 
application component 40. Figs. 3B-3D illustrate an adapter 
5 42, a service or facility 44, and a domain object resource 
model 46, respectively. OSS application component 40 
represents a software application component which implements 
one or more activities of a business process. Adapter 42 is a 
component that allows an OSS to communicate externally, such 
10 as with another service provider's system. For example, 

adapter 42 may support protocols such as facsimile, e-mail, 
EDI, FTP, CMIP, and the like. Service or facility component 
44 is a component that provides functionality common to 
application components. Components 44 are common so that they 
15 can be shared by different products. Domain object resource 
models 46 are services which model entities involved in 
telecommunication business processes for operations, planning 
and engineering, service provisioning, customer care and 
billing, and the like. These entities, represented by 
2 0 objects, model both state (attributes) and behavior. 

Exemplary domain object resource models 4 6 include customer, 
product, service, order, and network elements. 

Shown in Fig 4. is one particular embodiment of an 
OSS 50 and is included to illustrate various OSS application 
25 components which may be coupled to the various platforms. For 
example, an order entry component 52 is a component which 
facilitates the entering of various order informatipn into the 
sys-tem as described in greater detail hereinafter. A service 
management layer (network facing) platform 54 includes the 
30 following components: a local service management component 
56, an order management component 58, a mutual compensation 
rater component 60, a mutual compensation biller component 62 
and a mutual compensation reconciliation component 64. The- 
order entry component 52 is coupled to a service management 
35 layer (customer facing) platform 53 . Exemplary uses of these 
components are described hereinafter. 

Coupled to a network management^ layer platform 6 6 i's 
a service activation component 68, an inventory management 
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component 70, a workforce management component 72 and a usage 
mediation component 74. Finally, coupled to an element 
management layer platform 76 is a usage collection component 
78. The various components coupled to platforms 53, 54, 66 
5 and 76 are particularly useful in facilitating a local service 
request and for the exchange of billing information between 
different service providers as described in greater detail 
hereinafter. As such, it will be appreciated that the various 
components coupled to OSS 5 0 are merely representative of the 

10 various components may be coupled to the OSS to provide 
various services to customers. 

OSS 5 0 further includes various mediators which 
provide access control, translation and filtering of data 
between the various platforms. An output manager 80 is 

15 further provided and is coupled to various adapters which 
allow for exteinal communication. Output manager 8 0 is 
similar to the Inter- SP Gateway of Fig. 1 and gateway 32 of ' 
Fig. 2. Exemplary adapters which may be coupled to output 
manager 80 include an EDI adaptor 82, an e-mail adaptor 84, a 

2 0 fax adaptor 86, a FTP adaptor 88, as well as other adapters, 
such as adaptor 90 which are useful in transferring data from 
OSS 50 to another OSS. 

Coupled to each of the platforms via an information 
bus are one or more domain object resource models. For 

25 example, coupled to platform 53 is a customer model 82, a 

product model 84 and an order model 86. Customer model 82 is 
a service that is employed to store information associated 
with a customer and provides a set of screens on a user 
interface computer 87. Such screens, in turn, are employed to 

30 solicit and record information regarding a customer. Product 
model 84 includes information on the various 

telecommunications products that a customer may order. Order 
model 86 cooperates with ■ customer model 82 and product model 
84 and is employed to produce a series of screens on computer 
35 87 which solicit and record information necessary to fulfill a 
particular order for a customer. 

Coupled to platform 54 is a service provider model " 
88, and order fulfillment model 90, a service model 92 and a 
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local service request" model 94. Service provider model 8 8 
includes information regarding which services are offered by 
which service providers and typically includes the 
intraconnection agreements between service providers. Service 
model 92 contains information on the services that comprise 
the products, as well as the tasks and dependencies that are 
necessary to deliver the service. Order fulfillment model 90 
is created by order management component 5 8 to contain a list 
of tasks and dependencies necessary to fulfill an order. 
Order management component 58 uses information from order 
fulfillment model 90 and appropriate . service models 92 to 
create this list. Local service request model 94 is employed 
to store information- from customer model 82, order model 86, 
service provider model 88 and service model 92 so that . a local 
service request may be sent to another service provider. 

Coupled to network management platform 66 is a 
network topology model 96, a network element model 98, a 
service elements model 100, a workforce model 102, a physical 
inventory model 104 and a virtual inventory model 106. 
Physical inventory model 104 represents a collections of items 
that comprise the physical plant (e.g., cable pairs, • 
communication cards and the like) . Virtual inventory model 
106 includes a collection of virtual resources available 
within the network (e.g., bandwidth). Resource models 96-106 
work in cooperation with components 68-74 on network 
management layer platform 66 to assist in fulfilling a 
particular order. For instance, service activation component 
68 is provided to assist in configuring or provisioning one or 
more network elements 108 to provide the service requested by 
the customer. Inventory management component 70 identifies 
the resources, physical and virtual, that are necessary to 
deliver the requested services and adjust the- inventory levels 
appropriately. Once the resources have been identified, this 
may spawn additional tasks to order replacement stock, notify 
facilities planning of band width exhaustion and the like. 
Work force management component 72 dispatches technicians to 
install hardware, lay cable or otherwise modify the physical 
plant. Usage mediation component 74 is employed to normalize 
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call records received from various network elements into a 
common format . 

Resource models 96-106 include data that may be 
accessed by components 68-74. For example, network topology 
model 96 includes a description of the interconnection of 
network elements and their location. Network element model 98 
includes information on the actual network elements 98 that 
are available for use. Service elements 10 0 include 
information on the elements that comprise a service. A 
service element may be reused in one or more services. 
Workforce model 102 includes information on the needed and 
available technicians which will install or modify the ■ 
hardware or physical plant to deliver the product. Physical 
inventory model 106 includes a list of available inventory as 
well as required inventory for a particular product. Virtual 
inventory model 106 includes a list of available virtual 
inventory as well as the needed inventory required to 
implement a given product . 

Coupled to element management layer platform 76 is a 
functional entity model 110. Functional entity model 110 
includes detailed information necessary to provision a service 
element on a particular network element. In turn, such 
information is used by the network element management 
components to provision a' network element. Usage collection 
component 78 collects call records from network elements. 

Referring now to Fig, 5, one particular arrangement 
of an OSS 120' -will be described. For convenience of 
illustration, only a service management layer (customer 
facing) software platform or bus 122 and a service management 
layer (network facing) software bus or platform 124 are shown. 
It will be appreciated that a network management layer 
software bus or platform and an element management layer 
software bus or platform which are similar to those previously 
described herein will be coupled to OSS 120 by a mediator in a 
manner similar to that previously described. OSS 12 0 includes 
an output manager 12 6 to which various adapters may be coupled 
similar to the embodiment previously described in Fig. 4. 
Also similar to the embodiment of Fig. 4, a variety of domain 
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object resource models are coupled to the various software 
buses. Further, various components may be coupled to software 
buses 122 and 124 similar to the other embodiments described 
herein. Each of the components preferably includes a server 
to facilitate the transfer of information between the 
component and the software bus as is known in the art. 
Conveniently, a Legacy adaptor 12 8 may be coupled to software 
buses 122 and 124 to provide communication to external 
applications 130. For example, such external applications may 
include service order entry systems, trunk group assignment 
systems, such as SOAC and TIRKS, available from Bellcore. 

Coupled to layers 122 and 124 are a variety of- 
services or facilities. For example, a user interface tool 
132 provides various tools and facilities to support the 
creation and running of human interfaces 134, such as GUIs, 
for various OSS applications. User interface tools 132 
preferably include client service standards and models which 
provide documentation of standards and conventions for 
creating and partitioning client -server applications. For 
example, these standards may include detailed descriptions of 
how thin a client should be, including descriptions of what 
function should normally be performed in the sei-ver and what 
functions in the client. User interface tools 132 preferably 
also include look and feel standards on models which provide 
documentation of look and feel standards, including GUI style 
guides- They may also include code frameworks that implement 
the standards;- or- support easy implementation. User interface 
tools 132 may. further include tools and facilities to support 
the integration of test tools, and for testing GUIs. Tools 
and facilities may also be included to support integration of 
on-line help and documentation into application GUIs. 
Further, tools may be provided to support printing of any GUI 
screen, as displayed, along with any data on the screen. 

A distribution service 136 includes a directory 
service to provide the capability to locate services, 
facilities and other components, either by name or by seirvices 
offered. As one example, CORBA Trader and CORBA Naming 
services provide directory services and may be used with the 
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invention. Distribution service 13 6 further allows for the 
determination of what services are wanted based on incomplete 
information about that service. For example, it may- 
accomplished by allowing access to the CORBA Interface 
5 Repository. 

A security service 138 is further provided to verify 
the identity of a user by comparing a user ID and password 
with previously stored account information. The security 
service further uses information provided by an account 
10 management service (described hereinafter) to verify that a 

user has the appropriate privileges to access an application. 
Security service 13 8 may be based on existing CORBA security 
products , 

Transaction management service 140 synchronizes a 
15 unit of work, called a transaction which involves multiple 
components (applications, facilities or services) . In this 
way, all actions against individual components must be 
successful in order for the transaction to be successful. Any 
action that fails will cause all actions to be rolled back to 
20 restore to a previously known state. Transaction management 

service 14 0 may be based on a CORBA Object Transaction Service 
product . 

A business process management service 142 includes 
tools to aid in the definition, modification, execution and 

25 tracking of work processes. It also allows a user to define 
the order in which work will be done in response to given 
inputs or events. It further requires that the work being 
performed is divided into units that can be assembled in 
workflow. This service may be based on Workflow Management 

3 0 Consortium (WfMC) standards. 

Further coupled to layers 122 and 124 is a process 
management service 144 which includes tools and other 
facilities to support the administration of the pieces of the 
processes, data and other parts of individual applications. 

35 For' example, it may include facilities to start, stop, restart 
and otherwise manage the processes that make up an 
application. It also includes the ability to configure those 
processes, including the restart characteristics. Process 
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management service 144 further includes facilities to monitor 
aspects of an application, including the status of the 
processes. It may further extend the process management 
capabilities listed above to distributed applications, where 
5 the processes and data of an application are distributed 
across the network . 

A tunable management service 146 is included to 
provide facilities, including GUI, to browse tunables and sets 
of tunable values used to configure applications. It also 

10 includes facilities to effect updates at run time. 

A deployment service 14 8 is provided to support 
aspects of the deployment process. For example, this may 
cover deployment of OSS applications (i.e., applications built 
on the OSS framework) to the purchasers- of those applications. 

15 However, the same tools are also applicable to the deployment 
of releases of the OSS itself. For instance, deployment 
service 148 may be configured to- support the initial 
installation of a new product by providing tools which aid in 
the installation process, beyond what is provided by standard 

20 UNIX tools. It also allows for the installation of upgraded 

. versions of existing products. Deployment service 148 further 
provides support for packaging of releases, as well as in 
providing tools to aid in creation of patch releases. A patch 
may not contain the entire system, but only patches those few 

25 files that need to be patched to address a specific problem. 
Further, deployment service 14 8 may include tools to aid in 
organizing and^managing multiple . simultaneous releases or 
patches. It may further include tools to support and automate 
aspects of the distribution of releases for patches for 

30 . applications. 

An exception handling service 150 provides generic 
services to deal with exceptional conditions encountered at 
run-time. Although not all exceptional conditions are 
necessarily errors, this preferably includes the capability to 

3 5 define levels of error criticality. Exception handling 

service 150 may provide access to the generic log management 
capabilities (described hereinafter) to manage the error log." 
It may further include an object model for exceptions. By 
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defining a hierarchy of exiting exception class for use by OSS 
applications, functionality is allowed to be encapsulated and 
reused. Further, exception handling service 150 includes an 
object model for errors. 
5 A local time support service 152 includes tools to 

support the coordination of data and processes across multiple 
time zones. For example, this might include the ability for a 
GUI to display the local time of a time-stamp on a data object 
regardless of where the time -stamp was recorded. 

10 A log management service 154 is a generic feature 

that provides tools and facilities to manage any log 
maintained by the system. For example, it may provide a 
process of initially recording events for later use. It may 
also provide tools, typically GUI -based, to allow a user to 

15 scan through a section of a specified log, searching for 
events that match a desired set of criteria. Further, an 
interface may be provided to the reporting subsystem that ' ' 
allows selected entries from the log to be output in a 
formatted way and redirected to some output device. Log 

20 management seirvice 154 further includes tools and facilities 
for organizing the data in the log according to a user- 
specified set of criteria. Further, log management service 
154 may be employed to send a formatted and human readable 
version of a log to different devices/locations. For example, 

2 5 this might support redirecting the formatted log to the 
terminal, a printer, a file, e-mail, fax or the like. 

A login/logout service provides tools, including GUI 
and access to authentication information, to support logging 
in and logging out of users of the OSS applications. An 

30 account management service 158 provides administrative 

services for managing users of OSS applications. The service 
includes functions for creating, modifying, retrieving and 
deleting user acco\mts . "It also provides for the 
administration of both authentication information e.g., user- 

35 ID and password) and authorization information, i.e., what the 
user is allowed to do. Account management service 158 further 
provides functions for creating, modifying, retrieving and 
deleting user group definitions. 
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A trace log service 160 provides tools and 
facilities to support debugging and tracing application code. 
It also includes the ability to dynamically alter trace level 
at run-time. 

5 A report management service 162 provides tools and 

facilities to support the creation, scheduling and management 
of reports. For example, it may include a set of standard 
queries, or reports, for reporting on data associated with 
other OSS services and facilities. As one example, if a user 

10 administration function is provided, then the standard reports 
may include user, user group and related reports. Report 
management service 162 further includes tools and facilities . 
to allow the user to define their own reports, and then 
schedule the reports , redirect output and otherwise treat the 

15 reports as additional standard reports. It further includes 
tools to support scheduling of reports to be run at a 
specified time, at a specified frequency, with specified 
selection and sort criteria. The tools also allow changing of 
the scheduled attributes of existing schedule reports, as well 

2 0 as cancellation of those reports. It further provides an 
interface to generic output redirection tools to support 
redirection of report output to a selected output device, such 
as a fax, system file, e-mail, a named printer, the user 
screen or the like. 

2 5 A data store management service 163 maps data 

received or extracted from other components into a relational 
representation. It further encapsulates and presents a 
standard interface to allow access to the relational data. 

OSS 120 further includes an operational (Ops) data 

3 0 store 164 which is a temporary relational store to facilitate 

integration of existing (non OSS 120 compliant) systems. A 
data warehouse 166 is a long-term relational store that is 
optimized for reporting and decision support. 

As mentioned above, output manager 126 is 
35 responsible for managing the process of transferring 

information to and from another service provider or trading 
partner. The adapters convert the information into required' 
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formats (e.gr., EDI, fax, e-mail and the like as specified by 
various standard bodies such as OBF and ECIC) . 

Referring now to Fig. 6, a particular implementation 
of OSS 12 0 to support a scenario where a new customer requests 
5 a product and where another service provider provides one or 
more services that comprise the product will be described. 
For convenience of discussion, the elements in Fig. 6 which 
are essentially identical to those in Fig. 5 will use the same 
referenced numerals. It will further be ■ appreciated that the 

10 particular components included within Fig. 6 are merely 

representative of one set of components that may be coupled to 
the OSS system, and that other components, including those 
previously described in connection with Fig. 4, may also be 
coupled to the various layers to provide other services. 

15 In the following scenario, a new customer requests a 

telecommunications retail product. Such a product is 
typically a group of packaged services such as caller ID, call 
forwarding, and the like. Such services are typically bundled 
together by service providers into the telecommunications 

20 retail product. The particular service is described by a set 
of service elements which are independent of network element . 
A service element in turn is described by a set of functional 
elements which are network elements specific. In the 
scenario, another service provider provides one or more of the 

25 services that comprise the telecommunications retail product, 
thereby requiring the generation and transmittal of a local 
service request (LSR) to fulfill the order. 

To request the product, the customer contacts a 
customer service representative (CSR) . In turn, the CSR logs 

30 into an order entry component or application 170. The login 
screen seen by the CSR (and provided by login/ logout service 
15 6) collects the user ID and password from the CSR and passes 
the information to security service 138. In turn, security 
service 138 authenticates the identity of the CSR by comparing 

3 5 the user ID and password with those stored in a user account 
resource model 172.. Once verified, security service 138 
checks an access control list resource model 174 to authorized 
the CSR's access to order entory component 170. If 



aNSOOCID: <W0_9652321A1J_> 



wo 98/52321 P-CTAJS98/09697 

25 

authentication and authorization is successful, security 
service 138 notifies login/logout service 154 that the CSR is 
an approved user of order entry component 170. Otherwise, 
security service 13 8 notifies login/logout service 156 to deny 
5 the CSR access to the application. In this scenario, the CSR 
is an approved user of order entry component 170. Therefore, 
login/logout service 156 passes control to order entry 
component 170. In turn, order entry component 170 presents 
its main screen via terminal 171 to the CSR. 

10 Once logged in, the customer may contact the CSR to 

request a telecommunications retail product. The CSR 
determines that the customer is new, and uses the user 
interface provided by order entry component 170 to create a 
new instance of the customer model 82. In turn, the customer 

15 model 82 presents a series of screens to the CSR to solicit 
and record information from the customer. 

To create an order, the CSR describes the available 
telecommunications retail products to the customer from 
descriptive information presented, to the CSR by product model 

20 84. The customer then selects a desired telecommunications 

retail product. The CSR selects the "take order" process from 
the user interface provided by order entiry component 170. 
Order entry component 17 0 then creates an instance of order 
model 8 6 to hold the association between the customer and the 

25 selected product. Order model 86 presents a series of screens 
(derived from customer model 82 and product model 84) to the 
CSR to solicit, and record information necessary to fulfill the 
order from the customer. The products available to the 
customer is a function of the services that are available at 

3 0 the central office serving the delivery location. 

Order entry component 170 then passes the completed 
order model 86 to an order management component 176. Order 
management component 176, using the service models 92 that 
comprise the telecommunications retail product, decompose the 

3 5 order into a set of tasks and dependencies necessary to 
fulfill the order and uses this information to create an 
instance of the order fulfillment model 90 (which also 
includes an association with the originating order model 86) . 
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For the purposes of tTais scenario, another service provider 
provides one of the services to be delivered as part of the 
product. Although not described in reference to this 
scenario, it will be appreciated that other tasks will be 
5 necessary to fulfill the order, including service activation 

(provisioning) , inventory management and work force management 
as previously described. 

Order management component 176 passes order 
fulfillment model 90 to business process- management service 

10 142 to orchestrate the completion of the tasks. Business 
process management service 142 initiates tasks on various 
other applications and components, coordinating the work in 
accordance with the dependencies. As mentioned above, one 
task is to request another service provider to deliver a 

15 service to the customer. This task is passed to local service 
request management component 178, which, in turn, creates an . 
instance of the local service request model 94 and populates 
the model with information from the customer model 82, order 
model 86, service provider model 92 (which contains 

2 0 interconnection agreement information) and the appropriate 

service model 92 . Local service request management component 
178 passes the local service request model 94 and service 
provider model 88 to output manager 126 via a mediator 180. 

Output manager 126, using rules provided by service 
25 provider model 88, translates the local service request model 
94 into the LSR format required by the service provider, and 
manages delivery of the LSR through the appropriate 
interconnection adaptor (e.g., the EDI adaptor). In this 
manner, a LSR may be sent to another service provider to 

3 0 provide at least a portion of the service to the customer in a 

manner similar to that described in copending U.S Application 
Serial No. 60/068,166, previously incorporated by reference. 

Because various services will be provided by other 
service providers, a need will exist for exchanging billing 
35 information between the various service providers. Various 
components which may be used to implement a system for 
exchanging billing information are illustrated in Fig. 4. In 
particular, OSS 50 utilizes usage collection component 78, 
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usage mediation component 74, mutual compensation rater 60, 
mutual compensation biller 62, and mutual compensation 
reconciliation component 64, among others, to exchange billing 
information with one or more OSSs. As described in greater 
5 detail hereinafter, usage collection component 78 stores call 
records, such as Automated Message Accounting (AMA) records, 
from the network elements. Usage mediation component 74 
utilizes the raw data in the call records to create normalized 
call record objects. Mutual compensation rater 60 associates 

10 a fee structure with a call record. Mutual compensation 

biller 62 is employed to apply volume discounts, calculate 
taxes, and the like on an invoice basis to provide invoices 
for each account. Finally, mutual compensation reconciliation 
component 64 is employed to compare an incoming invoice 

15 received from another service provider via output manager 80, 
and an outgoing invoice to determine the financial obligations 
of each service provider. . . 

Still referring to Fig. 4, an exemplary method for 
processing mutual compensation billing information will be 

20 described. For convenience of discussion, the service 

provider operating OSS 50 will be referred to as service 
provider A (SPA) . Typically, SPA will bill another service 
provider, referred to as service provider B (SPB) , for 
termination of calls originated by SPB's customers. To do so, 

25 SPB produces a record of every call they either originate or. 
terminate. Each of these records has sufficient routing 
information to determine which originated calls were 
terminated by SPA. Similarly, SPA has the same information as 
regards to SPB. 

3 0 The method begins with the input of the call records 

from SPA'S switches into usage collection component 78. This 
information can* be automatically downloaded via an X.25 OSS 
connection or can be manually loaded via switch tapes. Usage 
collection component 78 continues to load the data provided by 

3 5 SPB to validate their invoice, typically provided in summary 
format via switch tape, or electronically via output manager 
80. 
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Usage mediation component 74 retrieves the raw data 
from usage collection component 78 through a mediator. Usage 
mediation component 74 creates call record objects out of the 
individual call records. Each of these call record objects is 
5 then stored in Ops data store 164 (see Fig. 5) . 

A user then logs in through user interface 87 and 
completes the process of identification and authorization to 
allow the user to use the billing system as described in 
connection with the previous scenario. Once logged in, the 

10 user begins the billing application and enters SPB as the 
billing/billed entity. 

Mutual compensation rater 60 and mutual compensation 
biller 62 retrieve the accounts receivable portion of the 
interconnection agreement for SPB from service provider model 

15 88, Components 60 and 62 load the relevant rating 

information, volume discounts, and the like from service 
provider model 88, and access Ops data store 164 (see Fig. 5) 
to collect all records that represent terminated calls that 
were originated by SPB. Components 60 and 62 apply the rating 

20 information to the call records and create an electronic 
invoice to be paid by SPB. 

Mutual compensation rater 60 and mutual compensation 
biller 62 further retrieve the accounts payable portion of the 
interconnection agreement for SPB from service provider model 

25 88. Components 60 and 62 load the relevant rating 

information, volume discount, and the like, and access Ops 
data store 164 to collect all records that represent 
originated calls that were terminated by SPB. Components 60 
and 62 apply the rating information to the call records and 

30 create an electronic invoice to be paid to SPB. 

Mutual compensation reconciliation component 64 then 
compares the two invoices and determines which service 
provider owes more. The service provider which owes more will 
then be credited the amount owed to it and component 64 

3 5 creates a bill for the remainder. This bill is forwarded to 
an accounts receivable or accounts payable portion of the 
service provider's accounting system as appropriate. 
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The invention has now been described in detail for 
purposes of clarity of understanding. However, it will be 
appreciated that certain changes and modifications may be 
practiced within the scope of the appended claims. 
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WHAT IS CIAIMED IS : ' 

1 1. A telecommunications system for use with at 

2 least one network element, the system comprising: 

3 a plurality of platforms, each platform having a 

4 defined functional responsibility; 

5 a plurality of components selectively attachable to 

6 the platforms, wherein the components of each platform operate 

7 together to perform various tasks within the functional 

8 responsibility of the platform, and wherein one of the 

9 platforms is adapted to be placed in communication with the 

10 network element to allow configuration information to be 

11 transmitted from the platform to the network element. 

1 2. A system as in claim 1, further comprising a 

2 gateway interconnecting at least some of the platforms, 

3 wherein the gateway includes an electronic interface to place 

4 the interconnected platforms in communication with other 

5 sez-vice provider systems . 

1 3. A system as in claim 1, further comprising 

2 mediators interconnecting each of the platforms, wherein the 

3 mediators include code to translate information which is 

4 transmitted between platforms. 

1 4. A system as in claim 1, wherein the defined 

2 functional responsibilities are selected from the group 

3 consisting of* -service management (customer facing), service 

4 management (network facing), network management, and network 

5 element management . 

1 5. A system as in claim 1, wherein the components 

2 are selected from the group of components consisting of 

3 network management systems, service order management systems, 

4 order entry systems, monitoring systems, billing systems, 

5 inventory systems, work force administration systems, rating 

6 systems, capacity planning systems, and network operations 

7 systems . 
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1 6. A system as in claim 1, wherein each platform 

2 includes a bus to channel information between each of the 

3 component s . 

1 7 . A system as in claim 1 , wherein one of the 

2 platforms comprises a network element manager platform which 

3 is adapted to interface with a plurality of network elements. 

1 8. 'A system as in claim 7, wherein the network 

2 elements are selected from the group consisting of STPs, SCPs 

3 and SSPs . 

1 9. A system as in claim 1, further comprising a 

2 data model which is in communication with at least some of the 

3 platforms, wherein the data model includes code for providing 

4 the state, attributes and behavior of telecommunications 

5 domain objects. 

1 10. A system as in claim 1, wherein at least one of 

2 the platforms includes at least one user interface. 

1 11. A telecommunications system, comprising: 

2 a plurality of platforms, each platform having a 

3 defined functional responsibility; 

4 a plurality of components selectively attachable to 

5 the platforms, wherein the components of each platform operate 

6 together to perform various tasks within the functional 

7 responsibility of the platform; and 

8 at least one network element in communication with 

9 one of the platforms to allow configuration information to be 
10 transmitted from the platform to the network element. 

1 12 . A method for providing telecommunications 

2 services, comprising: 

3 providing a plurality of platforms, wherein each 

4 platform is assigned a functional responsibility; 
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5 selectively- placing at least one component into each 

6 of the platforms, wherein each component performs a task 

7 within the functional responsibility of the platform; 

8 processing telecommiinications information relating 

9 to a service with the components; and 

10 transmitting at least some of the processed 

11 information to networks responsible for the delivery of 

12 telecommunications services. 

1 13 . A method as in claim 12, wherein each platform 

2 provides common services to each of its components to perform 

3 the task. 

1 14 . A method as in claim 12, wherein some of the 

2 components comprise application components, wherein one of the 

3 components comprises a service component, and further 

4 comprising determining with the service component the type of 

5 application components upon placement of the application 

6 components into a platform. 

1 15. A method as in claim 12, further comprising 

2 selectively placing a plurality of different components into 

3 each of the platforms, wherein the components in each platform 

4 cooperate together to perform various tasks within the 

5 functional responsibility of the platform. 

1 16. A method as in claim 15, wherein the functional 

2 responsibilities are selected from the group consisting of 

3 seirvice management (customer facing) , service management 

4 (network facing), network management, and network element 

5 management . 

1 17. A method as in claim 15, wherein the component 

2 is selected from the group of components consisting of order 

3 entry systems, order management systems, service provisioning 

4 management systems, inventory management systems, and work 

5 force administration systems. 
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1 18. A method as in claim 15, wherein the components 

2 are selected to provide a local number portability task, and 

3 wherein the transmitted information comprises call routing 

4 information which provisions the network elements. 

1 19. A method as in claim 15, further comprising 

2 translating at least some of the telecommunications 

3 information from one of the platforms and transmitting the 

4 translated information to at least one other platform. 

1 20. A method as in claim 15, further comprising 

2 translating at least some of the telecommunications 

3 information and transmitting the translated information to 

4 another service provider telecommunications system. 

1 21. A method as in claim 15, further comprising 

2 receiving telecommunications information from another service 

3 provider, translating the received information and 

4 transmitting the translated information to at least some of 

5 the platforms. 

1 22. A method as in claim 15, further comprising 

2 accessing information from at least one of the components wil:h 

3 a graphical user interface. 

1 23. A method as in claim 15, further comprising 

2 transmitting St:ate, behavior and usage information relating to 

3 telecommiinications domain objects to at least one of the 

4 platforms to assist the components in performing a task. 

1 24 . A method as in claim 23, wherein the state, 

2 behavior and usage information comprises network element 
'3 requirements, facilities requirements and work force 

4 requirements needed to accomplish a task. 

1 . 25. A method for. providing telecommunications 

2 services, comprising: 



wo 98/52321 



PCT/US98/09697 



34 

3 ordering a telecommunications service and entering 

4 the order into an order entry component interfaced with a 

5 service management (customer facing) platform; 

6 querying a data model through the service management 

7 (customer facing) platform to determine if the product is 

8 available for order; 

9 transmitting information relating to the order to a 

10 service management (network facing) platform having an order 

1 1 management component ; 

12 querying the data model through the service 

13 management (network facing) platform to determine the 

14 particular resources that are required to searvice the order; 

15 transmitting information relating to the order to a 

16 network management platform to determine if the particular 

17 resources are available to service the order; and 

18 transmitting information relating to the order to a 

19 network element management platform to service the order on a 
2 0 network element. 

1 . 26. An engine for use in a telecommunications 

2 system, comprising: 

3 a component which is adapted to selectively 

4 interface with a platform having a defined functional 

5 responsibility within the -telecommunications system, wherein 

6 the component includes code to assist in performing a task 

7 within the functional responsibility of the platform, whereby 

8 configuration- information may be transmitted from the platform 

9 to a network element . 

1 27. An engine as in claim 26, wherein the component 

2 is selected from the group of components consisting of network 

3 management systems, service order management systems, order 

4 entry systems, monitoring systems, billing systems, inventory 

5 systems, work force administration systems, rating systems, 

6 capacity planning systems, and network operations systems. 
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